As a general rule, the concepts and controls studied in the before chapter, “Security Fundamen- tals,” apply to both on-premises and cloud-based environments. Nonetheless, before moving your workloads to the cloud, you must determine what tasks will remain under your control and what tasks will be taken care of by the cloud service provider (CSP) of your choice. The sum of these efforts is usually referred to as the Shared Responsibility Model.
One noticeable challenge regarding cloud security is the inherent perception of loss of control. This initial suspicion may be a result of the lack of visibility into the provider’s environment or incompatibility of security tools and rules used in the cloud, as compared to those resources your company is familiar with. Although it may sound obvious, you should not move to a provider that you do not trust. And moving from doubt to trust does not mean simply verifying that the CSP has a famous security certification or accreditation displayed on its website. It is essential to understanding the security practices and controls available on the provider’s infrastructure and, even more important, how to enable and enforce those controls.
Generally speaking, physical controls are more readily available and consistent in the cloud. That happens because, in order to sound attractive and reliable to their potential customers, CSPs must invest in highly available data centers and enforce restrictive rules for physical access to facilities. Doing so might prove to be impracticable for most companies, which will, most frequently, have third parties in charge of those activities. Moreover, some IT security teams from more traditional organizations may frown at the need to take care of these physical aspects or even consider them as secondary concerns for someone who is in charge of infrastructure specifics.
As the pioneer and clear leader of the cloud service provider market, Amazon Web Services (AWS) has focused its development efforts on embedding security controls in each of its cloud services (such as Amazon EC2, Amazon S3, and Amazon VPC). In addition, AWS created innovative security services such as AWS Identity and Access Management (IAM), AWS Security Hub, Amazon GuardDuty, AWS Shield, AWS Web Application Firewall (WAF), AWS Key Management Service (KMS), Amazon Macie, AWS Artifact, Amazon Detective, and AWS Secrets Manager, among others. Moreover, AWS offers hundreds of industry-leading products from third-party security-focused partners to leverage existing controls and skills that are already in place in your organization.
Therefore, before you decide to move your first workload to the AWS Cloud, it is crucial that you familiarize yourself with the AWS security and compliance services, tools, best practices, and responsibilities, as well as have a good understanding of your own duties during your organization’s cloud adoption journey. With this background, you will be able to maintain and steadily improve your security posture using the AWS Cloud, creating a better security plan and implementing your security controls based on industry best practices, frameworks, and regulations with which your organization must be compliant.
AWS provides a global IT secure infrastructure, with compute, storage, networking, database, and higher-level services, like artificial intelligence (AI), machine learning (ML), analytics, and Internet of Things (IoT). To access the company’s more than 175 available services (at the time of this writing), you can use the AWS Console.
If you have ever watched an AWS presentation, you have probably observed that security is stated as AWS’s “job zero,” because of the company’s mission to release cloud services with embedded security controls and divulge best practices on how to use them. Embedding security controls in the cloud services and establishing best practices for them will ensure that your cloud environments are compliant with security evaluations and certifica tions based on the AWS Information Security Management System (ISMS). This includes a set of AWS information security policies, and processes, as well as industry-specific security and compliance frameworks.
The Shared Responsibility Model defines the boundaries and responsibilities belonging to AWS and those belonging to the customer regarding security and compliance. Generally speaking, AWS is in charge of security and compliance of the cloud, and customers are in charge of security and compliance in the cloud. But what exactly does that mean in real-life scenarios?
Because it is responsible for the security of the cloud, AWS controls (and is accountable for) the security and compliance aspects of its infrastructure, which includes hardware and software.
AWS is in charge of physical security and compliance of all data center facilities, in all regions, availability zones, and edge locations. AWS is also responsible for hardware security in all of its facilities around the globe, as well as for compute, storage, database, and networking security. For instance, AWS executes patch management in all routers, switches, and network equipment that are part of the AWS network infrastructure. In the same way, customers own the security management in all storage and computing resources that they have requested and that were provisioned by the AWS Cloud.
As you can see in next figure, AWS is responsible for implementing the security of the software layer that runs on top of the hardware components. One example of this layer is a hypervisor, which is the underlying platform that virtualizes CPU, storage, and networking infrastructure. Through such software, AWS leverages a rich set of management capabilities and also controls how these hardware systems will serve each AWS customer.
Consequently, when you create your Amazon EC2 instance, AWS is in charge of implementing the security patches, hardening guidelines, and best practices in the hypervisor layer. You are in charge of updating the instance’s operating system (OS) patches, imple- menting system configuration best practices, and creating security policies that align with your organization’s security policy.
AWS uses two different hypervisors: Nitro and Xen. The launch of C5 instances introduced a new hypervisor for Amazon EC2, the Nitro Hypervisor, that is built on core Linux Kernel-based Virtual Machine (KVM) but that does not include general-purpose OS components. Eventually, all new instance types will use the Nitro Hypervisor, but in the short term, some new instance types will continue to use Xen depending on the requirements of the platform. Note that AWS uses a customized and hardened version of the Xen hypervisor.
you can see that you (as an AWS customer) are always in charge of data encryption, OS security (in the case of Amazon EC2 instances), network firewall rules and configurations, IAM throughout your AWS Cloud environment (including your Amazon VPCs and AWS accounts), and your own application security that is running in the AWS Cloud.
As a cloud security professional, you should remember that AWS offers a variety of cloud services, such as Amazon EC2 instances, Amazon RDS databases, and AWS Lambda functions. The Shared Responsibility Model has features that depend on the type of service you are deploying. To understand such idiosyncrasies, the next sections will discuss three main categories of AWS compute services and how each of them produces a slightly different responsibility division between AWS and the customer.
The infrastructure category includes AWS Cloud services such as Amazon EC2, Amazon Elastic Block Store (Amazon EBS), AWS Auto Scaling, and Amazon Virtual Private Cloud (Amazon VPC). Therefore, if you are deploying such services, you are in charge of the deployed operating system, security controls, identity and access management, data encryption, firewall rules, and network configuration
The container services category includes AWS services that commonly run on Amazon EC2 instances (or other compute instances available in the AWS Cloud) where you, as a customer, do not manage their OS or their platform components. In such services, AWS manages more elements when compared to services that belong to the infrastructure category, providing application “containers.”
This AWS definition is distinct from the concept of “container platforms” such as Docker and Linux Containers (LXC).
As you can see in Figure 2.3, customers are in charge of data protection and encryption, network traffic protection, firewall access rules definitions, and IAM administration of their AWS accounts and environments. And in such scenarios, AWS takes care of the container platform and management (including patching), and OS security controls, as well as all other lower-layer-based controls.
The AWS shared responsibility for container services applies to AWS services such as Amazon RDS and Amazon Elastic MapReduce (EMR) because AWS manages the underlying infrastructure, the OS, and their application platform. Because they are managed services, their AWS-controlled application platform also offers more sophisticated features such as data backup and recovery tools. Nonetheless, it is up to you to define and configure your disaster recovery and business continuity policy.
The abstracted services category encompasses higher-level services such as Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (SQS), and Amazon Simple Email Service (Amazon SES). As a customer, in these cases you are interacting with only AWS endpoints and APIs whereas AWS manages all of their components, applications, and the operating system. As a customer, you are using a multitenant platform that is configured to securely isolate your data.
you can see that, as a customer, you are still in charge of data protection using encryption as well as IAM policies and rules definitions in services that belong to the abstracted services category.
AWS provides a set of documents with security best practices for each one of its cloud services. These documents are intended to help you implement your controls in your cloud environments on the AWS Cloud platform. You will find this web page at docs.aws.amazon.com/security.
When you are running your workloads in the AWS Cloud, you inherit all the security controls and compliance best practices that AWS has developed for its most securitydemanding customers. Also, due to its global presence, AWS must comply with various regulations and best practices for security, compliance, and data protection around the world. All certifications and compliance programs that AWS supports can be found in the AWS Compliance Programs site ( aws.amazon.com/compliance/programs )
The process of defining the cloud service provider that will be used to run your work- loads should include an evaluation of the provider’s security controls, best practices, and certifications that are relevant to your industry and organization. Some of the security best practices and standards you must consider are as follows:
ISO 27001: A standard from the International Organization for Standardization, ISO 27001 is part of the ISO 27000 information security standards family. It is used to define and implement an information security management system (ISMS), which helps companies to manage information assets that include sensitive data. This standard also leverages ISO 27002 as the basis for security controls best practices.
ISO 27017: Another standard that is part of the ISO 27000 family, ISO 27017 is focused on the information security practices for cloud computing. It defines the best practices and security controls that a cloud service provider must implement, supplementing the guidance explained in ISO 27002.
ISO 27018: This standard establishes commonly accepted control objectives, controls, and guidelines to protect personally identifiable information (PII) for public cloud computing environments.
PCI DSS: As briefly mentioned in Chapter 1, the Payment Card Industry Data Security Standard is an information security standard for organizations that handle and store credit card information.
CSA STAR: The Cloud Security Alliance (CSA) is a not-for-profit organization with a mission to promote the use of best practices for providing security assurance within cloud computing environments. The CSA Security, Trust, Assurance, and Risk (STAR) level 3 standard helps cloud service providers, customers, auditors, and consultants to verify that available cloud security controls meet the adequate level of assurance required to protect data.
SOC 1, SOC 2, and SOC 3: The System and Organization Controls (SOC) reports are independent third-party examination reports that demonstrate how AWS achieves compliance and controls objectives, helping your auditors to understand the AWS security control models. There are four critical reports. You can access three of them using the AWS Artifact portal, and the other one is publicly available.
In case you decide to focus your attention on the PCI DSS standard, AWS has published a very interesting report that you can refer to when implementing security controls based on the Shared Responsibility Model. You can find the report at d1.awsstatic.com/whitepapers/compliance/AWS_Anitian_Workbook_PCI_Cloud_Compliance.pdf, and a glimpse of its table of contents is shown in Figure 2.7. This report can also help you understand the technical controls that you must implement as a part of your responsibility. Such technical controls are IAM controls and firewall and network access rules, among many others.
The next figure (and at aws.amazon.com/compliance/csa), you can see that AWS is in compliance with the CSA STAR while also providing the CSA STAR Consensus Assessment, which explains how AWS is implementing the controls the standard requires. The latter can be found here: d1.awsstatic.com/whitepapers/compliance/CSA_Consensus_Assessments_Initiative_Questionnaire.pdf.
The AWS SOC 1 Type 2 Report evaluates the effectiveness of AWS controls that might affect internal controls over financial reporting (ICFR), and the auditing process is aligned to the SSAE 18 and ISAE 3402 standards. The AWS SOC 2 Privacy Type I Report assesses the AWS controls that meet the American Institute of Certified Public Accountants (AICPA) criteria for privacy. The AWS SOC 2 Security, Availability, & Confidentiality Report assesses the AWS controls that meet the American Institute of Certified Public Accountants (AICPA) criteria for security, availability, and confidentiality. Finally, the AWS SOC 3 Security, Availability, & Confidentiality Report summarizes the AWS SOC 2 report.
Using the ISO 27000 certifications, SOC Reports, and other necessary regulations and accreditation models, you can evaluate how the security controls are implemented in the AWS data centers and services, and thus determine whether the level of compliance will achieve the protection you desire for your business.
Even if PCI DSS is not a requirement for your business, the security controls discussed in the standard can and should be used as a basis for you to define the controls needed for your environment, especially when you are dealing with sensitive data.
Once you define the controls, certifications, and regulations necessary to meet your business protection requirements, you will need to perform periodic assessments and audits of those controls in AWS. Using a model based on total transparency and self-service principles, AWS created a service portal called AWS Artifact. You can access the Artifact portal using the AWS Console directly, and there are no costs to use it.
In AWS Artifact, you can generate the compliance reports that allow you to evaluate the AWS security controls and posture independently. In the cases of ISO and SOC reports, the available reports are generated by third-party independent companies.
The AWS Well-Architected Framework was developed to help you, as a customer, build secure, high-performing, resilient, and efficient infrastructure for your applications. The framework defines best practices in five pillars: security, operational excellence, reliability, performance efficiency, and cost optimization.
The AWS Well-Architected security pillar shows how you can implement a strong security posture in the cloud, defining and implementing security best practices to protect systems and information, while also generating business value for your organization.
The security pillar has seven security design principles:
Implement a Strong Identity Foundation: Use the least privilege principle (which is based on the zero-trust security model explained in Chapter 1) by creating segregation of duties (SoD), using the proper IAM roles and permissions, defining the appropriate authorization for each resource that will interact with the AWS Cloud, and limiting and centralizing privileged accesses and eliminating long-term credentials when possible.
Enable Traceability: Enable audit logs by centralizing log collection, ingestion, protection, and enrichment, and by creating alerts that should be monitored by one or several teams that will respond to each kind of alert, based on required runbooks and playbooks.
Apply Security at All Layers: Defense-in-depth is a must; you cannot use just one layer of protection but must implement network security, OS security, load balancer security, application security, and so on. You must implement security best practices in all AWS Cloud services and components that will be a part of your application.
Automate Security Best Practices: Automation is a key function in cloud security. The best way to deploy an agile and secure environment is to leverage automation, implement security as code, and transform your paper security policies into real and coded security controls. As you create infrastructure as code and insert embedded security controls to achieve automated security, you can scale your cloud environments while maintaining the same level of protection.
Protect Data in Transit and at Rest: You must understand your data in order to protect sensitive information in both data exchange and storage, using encryption, tokeniza tion, and masking resources to achieve it. You should also create and enforce access control policies to limit access to sensitive data wherever it is.
Keep People Away from Data: You must create mechanisms and tools to reduce or eliminate manual and human access to production data, thus reducing operation risks related to human mistakes when handling sensitive data.
Prepare for Security Events: You must define an incident response management practice, running incident simulations, creating tools, using automation, and running playbooks to improve the security incident capabilities.
The security design principles from the AWS Well-Architected Framework’s security pillar also define five best practice areas for security in the cloud that will be covered in the following chapters of this study guide:
Since November 2018, you can execute automated assessments in your AWS environments using the AWS Well-Architected Tool.
Although the AWS Certified Security Specialty certification does not explicitly require a deep knowledge of the AWS Well-Architected Framework, it is essential to read and study the framework to deepen your expertise in the best practices not only in security but in the other pillars as well.
IAM users are people or applications in your organization. They persist within the AWS accounts where they were created, but may have cross-account permissions if configured to do so. Each IAM user has its own username and password that give them access to the AWS Console. Additionally, it’s also possible to create an access key to provide users with programmatic access to AWS resources.
IAM users is a concept that gives administrators the granularity required to control how users should interact with AWS resources. You should notice that an IAM user is not necessarily a person. It can be an application (such as SalesApp) that runs on AWS or on your corporate network and needs to interact with resources in your account. If your application is running on AWS, you should use IAM roles to provide temporary credentials for the application to access AWS resources. However, if your application is running on your corporate network, you can create an IAM user and generate access keys, so SalesApp can have the required credentials to access your resources.
In order to avoid using your root user account, you should create an IAM user for yourself and then assign administrator permissions for your account so that you can add more users when needed.
Always remember to enforce the zero trust model’s principle of least privilege when creating your users—that is, users should have only the minimum required permissions to perform the tasks they need. You should define finegrained policies associated with your IAM users. Policies will be covered later in this chapter in the “Access Management with Policies and Permissions” section.
An IAM group is a good way to allow administrators to manage users with similar permissions requirements. Administrators can create groups that are related to job functions or teams such as administrators, developers, QA, FinOps, operations, and so on. They can then assign fine-grained permissions to these groups.
When you add IAM users to a group, they inherit the group’s permissions. With such a simple practice, it becomes easier to manage bulk changes in your environment and move IAM users around as they change or gain new responsibilities in the company. One important thing for you to note: An IAM group is not an identity because it cannot be referred to as a principal when you’re setting up permission policies. It is just a logical organization that allows you to attach policies to multiple users all at once.
Try to avoid assigning permissions directly to IAM users since these permissions are hard to track when your organization scales and users move to different organizational positions. The next figure describes the relation between users and groups with their related permissions.